1. Field of the Invention
The present invention relates generally to software architectures that provide platforms for distributed computing in a computer network and more particularly to a novel distributed virtual machine architecture that provides a platform on which existing network and standalone applications may execute in a network mode independent of any other underlying platform within the network.
2. Description of the Related Art
Distributed computing is the process of aggregating the computing resources of several computing entities to run collaboratively a single computational task in a transparent and coherent way, so that these entities appear as a single, centralized system. Various types of hardware and software systems on which processes may be distributed throughout a network of computing devices are known. Of primary importance to the disclosure herein are software systems that are designed to connect the users and computing resources of network devices in a transparent, open, and scalable way. The network itself may be any type of local area or wide area network interconnecting computing devices, as well as any interconnected combinations of any of these networks.
In one type of framework for distributed computing, several components of executable code are concurrently running on different computing devices in the network. In this particular framework, each of these components, although distributed among different network devices, is nonetheless designed to operate in a standalone mode on its respective host device. Distributed computing in this framework is then made possible by a system of protocols that enable any one of these components running upon one network device to exchange data over the network with a complementary component running on another network device. Two specific examples of the forgoing framework include the client-server and the peer-to-peer frameworks.
In an exemplary client-server framework, executable code running on the client sends, such as in response to user input entered into a user interface, a request for data over the network to the server. Executable code at the server, operating in response to the client request, generates the data and then sends the data back over the network to the client device. The code running at the client then processes the received data and renders such data for the user interface. Furthermore, many such clients may be making requests for data from a single server. Accordingly, not only does such server provide a service to multiple clients, it may also need to manage resources of the network on which such server and clients reside.
In an exemplary peer-to-peer framework there is no dedicated network device that provides a service or manages the network resources. Instead, all responsibilities are uniformly divided among all network devices, known as peers. For example, in some file sharing systems similar components of executable code are respectively running at two peers and each are generating data in response to user input. This data is then transferred between the peers over the network and the executable code at each peer receiving the data then renders such data for the user interface.
Although application processes running on the above exemplary frameworks are generally referred to as network applications, the code running on each network device to implement the exchange of data over the network is a fully functional standalone application on its host. It is only through consuming data, which has been developed at another network device and received from the network, do such application processes provide a useful user experience.
Moreover, in the above exemplary client-server framework, the server in particular bears the onus of the computational overhead of the network application by generating data in response to requests from multiple clients. Each client merely renders and formats the received data it receives in a prescribed protocol for the user interface. As the data is changing at the server, the previously rendered data at any client remains static until it is updated by a further request from such client. Accordingly, the computing resources of the networked devices are minimally aggregated.
Other software systems for distributed computing are known in which a network application may utilize more fully the aggregate computing resources of the network devices. However, in general, these systems may impose a significant burden on the programmer tasked with writing the network application by requiring the implementation and administration of features that are not central to the functioning of its distributed components. Examples of these systems are native implementations of network applications and XML messaging.
Native implementations of the network application are inherently limited in their ability to execute on a variety of different platforms, because any native implementation of the network application must be written and maintained for every target platform on which the network application will execute. Accordingly, these native implementations disadvantageously bind the program developers into a regimen of release versions tailored for every change of any one of the target platforms. Furthermore, changes to any one of the target platforms may further disadvantageously limit the programmer's ability to provide and distribute bug fixes and to maintain compatibility with the variety of platforms.
XML messaging, commonly used in web based frameworks such as SOAP, J2EE, and some proprietary technologies such as Macromedia's Flash and ActionScript, are inherently limited due to interoperability problems. For example, each component of executable code receiving an XML message must have knowledge of the XML tags from a document type definition or schema; otherwise the code will be unable to interpret the data. XML messaging is further disadvantageous in that it is an extremely inefficient method for transmitting data structures between each component of code.
Many network applications are now developed using object oriented programming, which is a method of programming that abstracts a computer program into manageable sections. The basis of object oriented programming is the concept of encapsulation.
Encapsulation is a methodology that combines the subroutines, or methods, that manipulate data with the declaration and storage of that data. This encapsulation prevents the data from arbitrarily being accessed by other program subroutines, or objects. When an object is invoked, the associated data is available and can be manipulated by any of the methods that are defined within the object to act upon the data.
The basic component of encapsulation is a class. A class is an abstraction for a set of objects that share the same structure and behavior. An object is a single instance of a class that retains the structure and behavior of the class. Objects also contain methods that are the processes that instruct an object to perform some procedure or manipulation of data that the object controls. Classes may also be characterized by their interface that defines the elements necessary for proper communication between objects.
In an object oriented distributed computing platform an object in a first network device, or a first address space, may seamlessly communicate with and manipulate an object contained in a second network device, or second address space. This type of distributed computing platform also allows for the removal of the communication protocols from the application components, or objects, and placement of the protocols in a mid-level software layer that manages communications across a computer network to facilitate a client's access to and manipulation of data contained on a server.
Distributed computing and object oriented programming have led to the development of distributed object management systems. These distributed object management systems are generally referred to as object request brokers. When an object on a client requests access to an object that exists on a server, the distributed object management system provides the communication link between the two devices and, thus, between the two objects. The distributed object management system removes the requirement of the client object communicating directly with the server object. Instead, current distributed object management systems utilize a remote proxy object on the client which models the interface of the server object. The client that requested access to the server object communicates with the remote proxy object that exists on the client. Therefore, the client can operate as if it is communicating directly with a local object. The remote proxy object contains the necessary communications information to allow the client to access and manipulate an object that actually exists on the server. Remote proxies allow the client to disregard the location of the requested object and the communication details.
A proxy is an object that has an interface and method list identical to another object. However, it does not contain the same detailed computer code. Instead it contains communications facilities that allow the proxy to communicate directly with another object without knowledge of the requesting object. Proxies can be used to control access to certain objects. They may also be used to remove the labor of network communications from local objects. For example, if object A residing on a first device needs to communicate with object B residing on a second device, object A must know the location of object B and have the necessary computer code to initiate communications with object B. A proxy for object B located on the first device allows object A to simply communicate with the proxy of object B as if object B resided on the same device. The proxy for object B has all the necessary information and computer code to communicate with the real object B on the second device. This type of proxy is known as a remote proxy since it exists on a device remote from the device that contains the requested object.
Systems heretofore known have required all possible remote proxies to be built when the software is initially compiled and loaded. This process imposes an administrative burden in ensuring that proxies are current with respect to the objects from which they are generated. In addition, software system designers must predict every possible remote proxy that may be needed in the future so that it can be built when the software is loaded. This process does not allow a system to adapt to its usage and environment. The requirement to implement and administer these features makes it disadvantageously difficult to write the code for a networked application, thereby limiting the availability of code that can truly be implemented in a distributed manner.
Furthermore, existing standalone software may need to be used within a distributed computing system. Many conventional object request brokers require an interface for each class for proper communications across a network. A user may not have access to the source code or may be restricted by license as to modifying the source code. Thus, the user may not be able to add interfaces, which allow classes to be used remotely in a distributed computing network, to class files within the existing software.
The object request brokers, described above, receive messages, determine the location of the receiving object, route the message to the receiving object, and perform all necessary platform and language translations. In object oriented programming, a message is typically a request sent to an object to change its state or to return a value. The object has encapsulated methods to implement the response to the received message. Using known prior art techniques, such as DCOM and CORBA, objects can communicate with remote objects residing in other network devices.
The availability of different object request brokers from different developers has resulted in several different communication protocols for transmission and reception of messages across a network. The communication protocol used by a particular object request broker may be referred to as its native protocol or native format. Conventional remote proxies generally have the communication protocol hard coded within the proxy.
CORBA compliant object request brokers utilize stubs and skeletons to provide inter-object communications across a network. The stub is on the requester side and sends messages across the network to a skeleton on the remote object side. The stub and skeleton take care of certain communication details between the requestor and the remote object. CORBA compliant object request brokers generally use a utility to generate a stub and skeleton for each class using information provided in an Interface Description Language (IDL) file for each object. However, when designing such network applications, there is disadvantageously a need to regenerate the stubs and skeletons during each iteration of the code-debug cycle.
Enterprise Java Beans (EJB) is an object oriented programming specification developed by Sun Microsystems for use with its Java™ computer programming language. When using EJB, certain mechanisms are interposed as an intermediate layer between a client object and a server object. This is generally accomplished by creating a wrapper class having the same methods as the object being wrapped and adding wrapping code in each method of the wrapper class. An example of the wrapping code would be adding security to the wrapped object such as limiting access to client objects with the proper password or key. Wrapper classes are generally generated at run time and add additional complexity to the distributed processing system in addition to negatively impacting system performance.
The Java™ programming language is an object-oriented programming language that is typically compiled into a platform-independent format, using a byte code instruction set, which can be executed on any platform supporting the Java virtual machine (JVM). Because the JVM may be implemented on any type of platform, implementing distributed programs using the JVM may significantly reduce the difficulties associated with developing network applications for distributed computing. Moreover, the JVM uses a Java remote method invocation system (RMI) that enables communication among programs of the system.
For example, in distributed computing using the Java programming language, objects flow between one network device and another network device when each network device transmits and receives method invocations using the JVM. For example, the first network device uses the RMI system for responding to a call for an object by converting the object into a byte stream, including an identification of the type of object transmitted and data constituting the object. While the first network device is responding to the call for the object, a process running either on the first network device or the second network device may continue operation without waiting for a response to its request.
The second network device receives the byte stream of the object. Using the RMI system, the second network device automatically converts the byte stream into the corresponding object, which is therefore a copy of the object and makes the object available for use by a program executing on the second network device. The second network device may also transmit the object to yet another network device by first converting the object into a byte stream and then sending it to the other network device, which also automatically converts the byte stream into the corresponding object.
The communication between these network devices sometimes involves, for example, repeated calls for the same information. These calls are made to a local proxy, which acts as a surrogate for the remote object in the address space of the client. Such a proxy will service the call by making a network request to the server object. Repeated calls to the same server object through a proxy can disadvantageously generate considerable network traffic, increasing the time and expense of obtaining the information. A further disadvantage and limitation of the Java RMI is that the programmer is required to add a special “remote” interface to the classes, and then run an offline utility to generate the proxies before the program is run.
As a result of these foregoing disadvantages and limitations of the prior art, interoperability among networked applications of any kind is virtually nonexistent. Native applications and web applications function largely in their separate universes, that is, despite the rhetoric of being called “networked applications,” they are in reality an aggregation of stand alone applications, each of which executes on its own dedicated device and merely exchanging data files across the network.